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A framework for rigorously specifying the behavior of concurrent 
systems is proposed. It is based on the widespread view of a concurrent 
system as a collection of interacting processes, but unlike previous 
approaches, no assumptions are made about the mechanisms for process 
synchronization and communi cation. One is able to describe the 
behavioral constraints imposed by such mechanisms without being forced 
to consider the details of process interaction, A key element of the 
proposed framework is a formal language that permits the expression of a 
broad range of logical and timing dependencies, many of which are 
inexpressible with existing techniques. The language is based on the 
five logical primitives: 'not 1 , 'and 1 , 'and^next 1 , 'and_next*' and 
'reverse' . 
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1,0 INTRQD.UCTIQM. 


A concurrent system, in simplified terms, is a collection of 
interacting elements. There may be as few as two or three elements, or 
as many as a thousand or even a million. The elements may be as simple 
as input switches or indicator lamps, or as omplex as entire 
processors. They may be tightly coupled and located in close proximity 
to one another, as in a highly parallel computer, or they may be loosely 
coupled and widely dispersed, as in a nationwide packet-swi tching 
network. The interactions may involve the simple synchronizat ion of two 
elements, or they may entail a complex communication governed by a 
communication protocol. 

A considerable number of attempts have been made to build concurrent 
systems that fall at different points in this multidimensional spectrum. 
Some of these attempts have succeeded, but many have been only 
marginally successful and a few have been outright failures. These 
experiences reflect a hard fact of life: the tools are not yet in hand 
that allow us to design concurrent systems in a risk-free fashion. The 
design of concurrent systems is today a difficult, risky and often 
painful endeavor. 


1.1 Specifying Behavior 


While there are undoubtedly several reasons for this state of 
affairs, one of the principal reasons must surely be our limited ability 
to specify - in a precise, straightforward way - the behavior of a 
concurrent system. For example, how do we express for a distributed 
flight-control system the relationships and dependencies among various 
sensor outputs, actuator inputs, status bits, and mode switches? The 
problem is compounded by the fact that some dependencies are functional 
in nature - engine thrust is a function of thrott 1 e- 1 ever position - 
while other dependencies are temporal in nature - landing gear lowered 
seven seconds before expected touchdown. Still others combine both 
functional and temporal requirements. 

Because of this limited ability, there is no way to rigorously state 
the required (intended) behavior of a concurrent system, and without 
such a formal statement, there is no way to rigorously verify that the 
actual behavior matches the required behavior. Moreover, there is no 
way to insure that the requirements are, in fact, consistent. But 
perhaps most importantly, there is no unambiguous medium for 
communicating ideas among the sponsors, implementors and users of a 
system. 

To those who object to the need for formal techniques and argue that 
the present informal methods are sufficient, there are two replies: (1) 

Informal methods have not been notably successful in alleviating the 


serious problems encountered in the design of concurrent systems* (2) 
Formal (i.e., mathematical) techniques have been extraordinarily 
successful in a variety of disciplines concerned with modelling system 
behavior. (One can only wonder where electrical and aeronautical 
engineering and control theory - to name a few disciplines - would be 
today without their mathematical underpinnings.) 


1.2 Background 


We propose a framework for rigorously specifying the behavior of 
concurrent systems. It is based on the widespread view of a concurrent 
system as a collection of interacting processes [6] [7] [8] [9] [10] 

Cl 6] [ 17 ] [20] [21] [25] . In this view, the behavior of each process 
is represented as a sequence of values, which - depending upon the model 
- are interpreted either as states or events (actions). 

Processes interact with one another, and thereby influence each 
other's behavior, by any one of a number of different ro^hani sms . It is 
these synchronization and communication mechanisms that have received 
the greatest attention. Semaphores [8], monitors [16], rendezvous [2] 
[5] [2k], path expressions [6], and exchange functions [ 9 ] [25]* are 
some of the methods that have been proposed and investigated. But 
because all of the above approaches are tied to a particular model of 
process interaction, they are limited in their generality and expressive 
power. The specification framework proposed here, however, is 
independent of the underlying synchronization and communication 
apparatus. It permits us to describe the behavioral constraints imposed 
by such mechanisms without forcing us to consider the details of process 
i nteracti on. 

Although this impl ementat i on- i ndependent approach increases 
generality, it also creates a technical problem. We must now be able to 
represent the composite behavior of a collection of interacting 
processes. These behavioral representations must reflect the local 
constraints imposed by individual processes, as well as the global 
constraints stemming from process interaction. Moreover, it must be 
possible to express essential constraints on behavior without being 
forced to include superfluous constraints. For example, it should not 
be necessary to assign a temporal ordering to two event occurrences if 
such an ordering is not essential to system behavior - that is, if the 
two occurrences are 1 concurrent 1 . This last requirement immediately 
excludes the use of sequences (linear orderings) of states or events to 
represent concurrent behavior - even though such sequences are used to 
describe the behavior of individual processes. 

The natural solution is to use par t ia 1 orders on event occurrences 
(or state holdings) to represent concurrent behavior. In such partial 
orders, two event occurrences are always ordered if they relate to the 
same process. If they relate to two different processes, then they may 
be either ordered or unordered (concurrent). Two interpretations can be 


2 



attached to the ordering relation. We may consider the ordering of two 
occurrences to mean that the first precedes the second in time (which 
assumes there is a global notion of time). Or we may consider the 
ordering to mean that there is a causal connection leading from the 
first to the second (which means that the first precedes the second by 
every temporal measure) . 

The use of partial orders to represent concurrent behavior is not 
novel. There has been research along these lines, [7] [10] [14] [ 1 8 ] , 
for many years. What is new in the present approach is a technique for 
characterizing a set of partial orders, a technique that permits us to 
express a broad range of logical and timing dependencies, many of which 
are inexpressible within existing approaches. 


1 . 3 Overview 


The system model (described in Section 2) provides the basis for a 
system specification. It is a multiprocess model in which the behavior 
of an individual process is represented by a sequence of values drawn 
from the process’s 'type*. The composite behavior of an entire system 
is represented by a partial order on ‘instances', each of which 
associates a process with a value. Instances may be interpreted either 
as occurrences of events or holdings of states. A partial order on 
instances is called a 'trace*. * : 

The proposed specification technique has four major components: (1) 

Type Definitions, (2) Process Declarations, (3) Synchronic Structure and 
(4) Logical Specification. Each Type Definition (described in 
Section 3) defines a set of values and a set of operations on those 
values. The format for Type Definitions is provided by the mechanisms 
of the Ada 1 programming language for declaring scalar and composite 
types. Process Declarations (also described in Section 3) assigns to 
each process a type. 

The purpose of the Synchronic Structure and Logical Specification is 
to specify, through restrictions, the set of permitted (or legal) 
traces. The restrictions imposed by the Synchronic Structure (described 
in Section 4) deal only with the structure of a trace when the values 
associated with instances are ignored. Through the Synchronic 
Structure, one can assign to a process a metric for time, which provides 
the basis for expressing timing constraints. 

The Logical Specification, in contrast to the Synchronic Structure, 
deals only with dependencies involving instance values. These 
dependencies am expressed in a formal language, two versions of which 
are defined. UPL (for UniProcess Language) (described in Section 5) *s 
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the simpler version but is restricted to single-process systems. MPL 
(for MultiProcess Language) (described in Section 6) has no restrictions 
but its semantics are more complex than those of UPL. UPL introduces 
the four logical primitives 

not and and_next andjiext* 

To these four, MPL adds 

reverse 

In both UPL and MPL, the first four primitives are used to define the 
five auxiliary constructs 

or or^next or_next* implies imp1ies_next 

Through these various primitives and constructs, it is possible to 
express a wide range of logical and timing dependencies. However, 
because these primitives and constructs are relatively Mow level*, UPL 
and MPL can be extended to include the following sorts of higher-level 
statements (in which P and Q represent either states or events, 
depending on context): 

• P is followed N time units later by Q. 

© Q is inevitable within N time units following P. 

• Q for N time units following P« 

• Following P, always Q. 

• Following P, Q as long as R. 

• Following P, Q until R. 

• Following P, Q is repeated every N time units. 

Each of these statements represents a statement in either standard UPL 
or standard MPL. 

The four components of a system specification - Type Definitions, 
Process Dec 1 arat i ons , Synchronic Structure and Logical Specif ication - 
are illustrated (in Section 7) for a simple example: the 

Alternating-Bit Protocol. 
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A ( mui ti process ) system is an ordered quadruple <T,P,D,2> where 
T is a set of types 
P is a set of procesaea 
D is a set of PLES.S&S 9E8.Upn> 

i 

X is a set of ftWSft i 

A type is a set of values . Process declarations is a mapping from the 
set of processes to the set of types. Each process p is thus 
associated, through its type, with a set of values - denoted Type(p). 
Both processes and values are considered here to be atomic entities. 

Although not essential, it is sometimes useful to consider two 
classes of processes: event processes and state processes. The values 

of an event process are interpreted as events, while the values of a 
state process are viewed as states. A communication port is typical of 
an event process since the values of the process are most usefully 
interpreted as the events of sending and receiving particular messages. 
Sensor outputs, displays, mode switches and status bits, however, are 
more conveniently represented as state processes since in these cases it 
is usefui to view behavior as a sequence or states. 2 In the parlance of 
modern software engineering (and the Ada programming language), a state 
process would be called an 'object*. 

The permitted traces of a system represent the allowed (or legal) 
behaviors of the system. Each trace is a partial order on a set of 
'instances'. 


2.1 Instances 


An \ nstance is a triple <p,v,n> where p is a process, v is a value 
in Type(p), and n is a positive integer. 3 Depending on whether p is 
interpreted as an event process or state process, <p,v,n> can be viewed 


Note that we are speaking here of 'local* states and not 'global* 
states . 

Adding a positive integer to an instance merely allows us to create 
distinct instances having the same process and value. The choice of 
positive integers is arbitrary - any countably infinite set will do. 
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as either the occurrence of an event or the holding of a state. For the 
instance <p,v,n>. 

Process (<p,v,n>) * p 

Value (<p,v,n>) « v 

We say that Instance <p,v,n> is an instance fif, Process p. Depending on 
the interpretation for p - as a state process or event process - <pfV,n> 
may be regarded as the condition of Process p assuming Value v or as the 
event of Process p performing the action represented by Value v. 


2.2 Traces 


A trace is a partial order on a finite set of instances such that 
all instances belonging to the same process are totally ordered. The 
restriction on the instances of a process means that the behavior of 
each process is represented by a (linear) sequence of values. 

The instances in a trace, like all instances, each have a positive 
integer associated with them. However, since these integers have no 
significance other than to distinguish instances having the same process 
and value, we consider two traces to be identical if they differ only in 
their integer assignments. 

Let T be a trace defining the partial order £ over a set I of 
instances. Then 


Instances (T) * I 

For x,y in Instances (T) , x precedes ( comes before ) y and y fol lows 
( comes after ) x if x<y. x and y are concurrent if x and y are unordered 
with respect to £ - that is, if neither x£y nor y£x. 

Notice that the foregoing relations depend only on the partial order 
defined by T and not on the process associated with each instance. That 
is not the case for two concepts central to our specification approach: 
the 'next 1 and 'last* relations. Let Process (x) c X and Process (y) *Y. 

Then y is the next instance of Y following x if y follows x and for all 
2 i n Instances (T) f 

2 follows x and Process (2) ^Process (y) *> 2«y or 2 follows y 

x is the last instance of X preceding y if x precedes y and for all z in 
Instances (T) , 

2 precedes y and Process (2) *Process (x) *> 2 *x or 2 precedes x 
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Note that because the instances of each process are totally ordered, if 
there are any instances of Process Y following (preceding) Instance x, 
then there must be a next (last) instance following (preceding) x. 


2*3 Example of a Trace 


A typical trace is illustrated pictorial ly in Figure 1. Eacn vertex 
represents an instance, with the vertex type indicating the associated 
process,. Thus 


Process (a 0 ) * A 
Process (a^ «* A 
Process (a 2 ) * A 
Process (a 3 ) * A 


Process (b 0 ) « B 
Process (b,) * B 
Process (b 2 ) ** B 
Process (b 3 ) « B 


An edge (arrow) leading from Instance x to Instance y means that x 
precedes y. Notice that the requirement that all instances belonging to 
the same process be totally ordered is satisfied. 


The trace in Figure 1 establishes a number of relationships among 
the eight instances. A few are listed here: 

a 0 precedes a 2 

a 2 follows a Q 

b 1 precedes a 3 

a 3 f ol lows 

a 1 and b 2 are concurrent 
and a 2 are concurrent 

b 3 is the next instance of Process B following a, 

a 1 is the last instance of Process A preceding b 3 

a 3 is the next instance of Process A following b 1 

b 2 is the last instance of Process B preceding a 3 

Note that the ‘next 1 and 'last' relations are not, in general, 
converses of one another. If x is an instance of Process X, y an 
instance of Proces* Y, and X and Y are not the same process, then the 
two relations 

y is the next instance of Process Y following x 
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Legend 

• Process A 
B Process B 


Figure 1 . A Trace 


x Is the last instance of Process X preceding y 


are independent. Both relations may hold, neither may hold, or one may 
hold without the other. For example, in Figure 1: 

• b 3 is the next instance of Process B following a t , and a., is the 
last instance of Process A preceding b 3 . 

• b 3 is not the next instance of Process B following a 0 , and a 0 is 
not the last instance of Process A preceding b 3 . 

• a 3 is the next instance of Process A following b 1t but b 1 is not 
the last instance of Process B preceding a 3 . 


If X and Y happen to be the same process, then the two relations are 
equivalent - they both hold or they both fail to hold. Thus, in 
Figure 1, a 2 is the next instance of Process A following a 1 , and a i is 
the last instance of Process A preceding a 2 . 


Although each vertex in Figure 1 is labelled with the name of an 
instance, in many cases we may wish to indicate expl i c t tl y the process 
and value associated with the instance. Since the process is already 
given by the vertex type, we need add only the value. Suppose, for 
example, that the type of Process A is Integer and that the type of 
Process B is Boolean. Suppose, furthermore, that 


Va!ue(a 0 ) “ 17 
Va I ue (a,) * -3 
Va l ue (a 2 ) « 
Value (a 3 ) » 9 


Va!ue(b 0 ) - T 
VafueCb^ * F 
Value(b 2 ) “ F 
Value (b 3 ) * T 


i 
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Then the trace in Figure 1 can be made explicit by replacing instance 
names with instance values as shown in Figure 2. 


2.h Permitted and Prohibited Traces 


Centra) to the notion of system is the idea of constrained behavior. 
Except for degenerate (and uninteresting) cases and except for 
malfunctions, the behavior of a system is constrained by certain bounds. 
Behaviors lying within those bounds are said to be permitted (or 
allowed, or legal, or possible), while those lying outside those bounds 
are said to be prohibited (or disallowed, or illegal, or impossible). 

In our system model we have chosen to represent system behaviors as 
partial orders on instances - traces. The set of permitted traces in 
the definition of a system (see '‘The System Model 11 on page 5) thus 
represent the permitted behaviors of the system. 


2.5 System Specification 


Having provided a formal model of system behavior, we turn now to 
the task of formally specifying that behavior. The framework described 
in the subsequent sections has four components, each of which can be 
related to the components of the system model. Type Definitions defines 
the process types, the values associated with each type, and the 
operations defined on each type. Process Declarations defines the 
processes and identifies their types. The Synchronic Structure and the 
Logical Specification together define the set of permitted traces. 


3.0 TYPES 


A type defines a set of values and a set of operations on those 
values. How then to specify a type? For a variety of reasons, it seems 
prudent to adopt the mechanisms of the Ada programming language for 
declaring scalar and composite types. 4 These mechanisms, which are 
quite extensive, provide the ability to define the sorts of structures 
likely to be encountered in specifying system behavior. Furthermore, by 
adopting Ada syntax, we insure compa t ib i 1 i ty of the specification 
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Legend 

+ Process A 
B Process B 


Figure 2. A Trace with Values 


language with what is likely to become the pre-eminent 
language for real-time, embedded systems. 


programming 


We will not attempt to give here a complete description of the Ada 
constructs for defining scalar and composite types. Any number of 

w?u r bTh e :; « W- W or [24], are adequate for Jhat ZpoL It 

will be helpful, however, to give a brief overview of the scalar and 
composite types illustrated in Figure 3. 


3*1 Enumeration Types 


Type definitions take the form 
type NAME is ... ; 


The words type' and 'is', as well as all other lower case words in our 
examples, are reserved words with special meanings in Ada and can be 
used only as indicated. 'NAME' is a user-supplied word that denotes the 

IT.- • 'T ^ -■ ''.presents the body of 

definition and must be filled in using an appropriate format. 
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In addition to scalar and 
private and task types, 
purposes and are omitted 


composite types, Ada also has access, 
These are not needed for speci f t cat ion 
from the discussion. 
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Type 


Scalar 


Composite 


Discrete Real Array Record 


Enumeration Integer 


Figure 3« Classification of Types 


Enumeration types are the simplest types. The type definition is 
merely a list of the type's values. Thus 

type NAME is (VALUE1 , VALUE2 , VALUE3) ; 

declares NAME to be an enumeration type with values: VALUE1 » VALUE2. and 
VALUE3. 

Of special interest is the predefined enumeration type BOOLEAN which 
may be considered to have the definition: 

type BOOLEAN is (FALSE.TRUE) ; 


3*2 Numeric Types 


There are two predefined numeric types, INTEGER and REAL. These may 
be used directly or subsets may be declared using the ‘subtype 1 
statement. The statement 

subtype NAME is INTEGER range M. *N; 

declares NAME to be a subtype of INTEGER that has just those integers in 
the range M to N inclusive as its values. A similar interpretation 
holds for the statement 

subtype NAME is REAL range M..N; 


3*3 Array Types 


The standard format for declaring an array type is: 
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type NAME is array (INDEX1_TYPE.INDEX2 JTYPE) of ELEMENT JTYPE; 

This statement declares NAME to be an array type whose values are 
two-dimensional arrays. INDEX1 provides the indices for the first 
dimension, and INDEX2 the indices for the second dimension. 
ELEMENTJTYPE indicates the type of elements making up the array. 


3.4 Record Types 


A record is a composite object with named components. A component 
of a record is accessed through its name using dot notation. If RECORD 
is a record object with a component named COMPONENT, then 
RECORD. COMPONENT denotes that component. The simplest format for 
declaring a record type is: 

type NAME is 
record 

. C0MP0NENT1: COMPONENT1 JTYPE; 

C0MP0NENT2: C0MP0NENT2 JTYPE ; 

C0MP0NENT3: COMPONENT3JTYPE ; 
end record; 

This statement says that NAME is a record type with three components: 
COMPONENTS C0MP0NENT2 and C0MP0NENT3- COMPONENTi JTYPE indicates the 
type of COMPONENTi . 

It is sometimes necessary to define a record type in which part of 
the structure is fixed for all objects of that type and part of the 
structure is variable. Depending on the value of a special component, 
called a 1 d i scr imi nant 1 , the variable part may assume one of several 
alternative forms. The format for declaring a discriminated-record type 
i s : 


type NAME (DISCRIMINANT: DISCRIMINANT JTYPE) is 
record 

COMPONENTI: COMPONENTI JTYPE; 
case DISCRIMINANT is 

when DISCRIMINANTJ/ALUE2 «=> 

C0MP0NENT2: C0MP0NENT2JTYPE ; 
when DISCRIMINANT VALUE3 *> 

C0MP0NENT3: COMPONENT 3 JTYPE ; 
end record; 

Here, DISCRIMINANT is a component of the NAME record type that helps 
determine the structure of the type. While COMPONENTI is common to all 
objects of the type. C0MP0NENT2 pertains only to those objects for which 
NAME. DISCRIMINANT takes on the value DISCRIMINANT_VALUE2, and COMPONENT3 
pertains only to those objects for which NAME . DISCRIMINANT takes on the 
value DISCRIMINANT_VALUE3. 
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3.5 Example of a Type Definition 


The Ada syntax just described provides an extensive capability for 
describing data structures, a capability that is illustrated in the 
following realistic example. It is a partial definition of the cockpit 
interface for a typical commercial aircraft. We emphasize that the 
definition is incomplete. 


type COCKPIT is 
record 

FLIGHT_C0NTR0L: FLIGHT CONTROL STATE; 

FLIGHT_MANAGEMENT: F LI GHT_HAN AGE MENT_ST ATE ; 

AIRCRAFT_SYSTEH_MANAGEMENT: AIRCRAFT_SYSTEH_MANAGEMENT_STATE; 

COHMUNICATION: COMMUNICATION_$TATE; 
end record; 

type F LIGHT_CONTROL_ST ATE is 
record 

INERTIAL: INERTIAL_STATE ; 

AIR_DATA: AIR_DATA_STATE ; 

RADIO_NAVIGATION: RADIO_NAVIGATION_STATE; 

FLIGHT_DIRECTOR: FLIGHT_DIRECTOR_STATE ; 

PRIMARY_PILOT_CONTROLS:~ PRIMARY_PILCT_CONTROLS_STATE ; 

SEC0NDARY_PIL0T_C0NTR0LS: SEC0NDARY^PIL0T_C0NTR0LS_STATE; 
end record; 

type INERTIAL_STATE is 
record 

PITCH: UNITS. DEGREES range -90.0. .+90.0; 

ROLE: UNITS. DEGREES range -180.0. .+180.0; 

HEADING: UNITS. AZIMUTH_DEGREES; 

RATc_OF_TURN: UNITS .DEGREES_PER_SECOND range -10.0. .+10.0; 

SLIP: UNITS. FEET_PER_SEC0ND2 range -10.0. .+10.0; 
end record; 

type AIR_DATA_STATE is 
record 

COMPUTED_AIR_SPEED : UNITS. KNOTS range 30.0..L50.0; 

HACh_NUHBER:~REAL range 0.0.. 0.9; 

ALTITUDE: UNITS. FEET range -1000. .L 50 OO; 

VERTICAL^SPEEO: UNITS. FEET_PER_MINUTE range -6000.0. .+6000.0; 
end record; 

type FLIGHT_DIRECTOR_STATE is 
record 

PITCH_COHHAND: DISPLAY_SCALE ; 

R0LL_C0HHAND: DISPLAY SCALE; 

« SPEED_COHMAND: DISPLAY_SCALE ; 

| AUTOPILOT: AUTOPILOT_hODE ; 

! end record; 
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type PRIMARY_PILOT_CONTROLS_STATE is 
record 

ROLL CONTROL WHEEL: UNITS. DEGREES range -70.0. .+70.0; 

PITCH CONTROL_COLUHN : UNITS. INCHES range -L.O. .+10.0; 

RUDDER_PEDAL: UNITS.INCHES range - 3 .O..+ 3 .O; 
end record; 

type HODE_DISCRIMINANT is (DISENGAGED, CONTROL_WHEEL_STEERING, COMMAND); 

type AUTOPILOTJIODE (AP_ENGAGE_HODE : MODEJJISCRIMINANT) is' 
record 

case AP_ENGAGE_KODE is 
when DISENGAGED «> 
null; 

when CONTROL_WHE E L_STEERING -> 
nul 1 ; 

when COMMAND -> 

THRUST SPEED: THRUST SPEED_SU8H0DE; 

VERTICAL: VERTICAL_$UBMODE; 

LATERAL: LATERAL_SUBMODE ; 
end record; 

type THRUST_SPEED_SUBMODE is 
record 

SPEED_HOLD: BOOLEAN; 

AUTO_THRUST: BOOLEAN; 

COMMANDED_SPEED: KNOTS range 30.0. .1*50.0; 
end record; 

type VERTICAL_SUBM0DE is 
record 

ALTITUDE HOLD: BOOLEAN; 

VERTICAL^SPEED: BOOLEAN; 

VERTICAL_NAV: BOOLEAN; 

COMMANDED_SPEED: FEET_PER_MINUTE range -3000.0. .+6000.0; 
COMMANDED_ALTITUDE : FEET range 0..L5000; 
end record; 

type LATERAL_SUBMODE is 
record 

HEADING HOLD: BOOLEAN; 

VOR: BOOLEAN; 

RNAV: BOOLEAN; 

LOCALIZER: BOOLEAN; 

LAND: BOOLEAN; 

SELECTED_COURSE: UNITS. AZIMUTH_DEGREES; 

COMMANDED_HEADING : UNITS. AZIMUTH_DEGREES; 

RUNWAY_HE ADING: UNITS . AZIMUTH_DEGREES; 
end record; 
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? type UNITS is 

j record 

| INCHES: REAL; 

FEET: INTEGER; 

| FEET_P£R_HINUTE: REAL; 

{ FEET_PER_SECON02: REAL; 

.j KNOTS: REAL; 

1 DEGREES: REAL; 

| AZIMUTH DEGREES: DEGREES range O.O. .359*9; 

DEGREE S_PER_SECOND: REAL; 
l end record; 

j type DISPLAY_SCALE is REAL range -100.0. .+100 .0; 



3.6 Process Declarations 


Once an appropriate set of types has been defined, the processes of 
a system can be declared. There are three possible formats for a 
process declaration: 

PRQCES$_NAME is of type TYPE^NAME; 

PR0CESS_NAME is an event process of type TYPE_NAME; 

* , 

PR0CESS_NAHE is a state process of type TYPE_NAHE; f 

.i 

The first format is used when the values defined by TYPE_NAME are to be j 

left uni nterpreted, the second means that the values are to be ; 

interpreted as events, while the third means that the values are to be 
interpreted as states. 


A.O SYNCHRONIC STRUCTURE 


The purpose of a synchronic structure - described in this section - 
and a logical specification - described in the next section - is to 
specify, through restrictions, the set of permitted traces. , The two 
types of specifications, however, provide two different sorts of 
restrictions. The constraints imposed by a synchronic structure deal 
only with the structure of a trace when the values associated with each 
instance are ignored. For example, one might want to require that 
between any two instances belonging to Process A there are 7 instances 
belonging to Process B. This restriction says nothing whatsoever about 
values. A logical spec i f icat ion, on the other hand, deals entirely with 

i 
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dependencies involving values. Example: If Process A takes on Value vl, 
then the next value taken on by Process B is v2. 

The class of restrictions that we have chosen to call ‘synchronic* 
is quite large and encompasses many extremely complex relationships. We 
will not attempt to specify all such restrictions, but will focus 
instead on a subset of those restrictions that permit us to express 
logical and timing dependencies in a unified way. 


4.1 Synchronous and Asynchronous Processes 


So far we have said nothing about time. We have spoken only of 
instances and partial orders on instances. It is clear, however, that 
in order to specify real-time behavior, a way must be found to express 
timing dependencies. 

An obvious approach is to augment the definition of a trace by 
adding durations either to instances - for a state process - or to edges 
- for an event process. In the first case, the duration represents the 
duration of a state holding, while in the second case the duration 
represents the elapsed time between two event occurrences. This 
approach, while perhaps workable, introduces a second level of discourse 
for expressing timing dependencies. It means having to express logical 
relationships and timing relationships using two separate sets of 
notions, a troublesome situation when the logic and timing of system 
behavior are intertwined, as is often the case. 


By following a slightly different course, it is possible to express 
both logical and timing requirements within a single, unified framework. 
This is accomplished by attaching to a process a granular i tv (of time). 
For example, we might declare Process A to have a granularity of one 
nanosecond. If Process A is a state process, then each instance of 
Process A represents a state holding having a duration of one 
nanosecond. A state holding with a longer duration is represented as a 
sequence of instances. Thus, to represent a holding of five 
nanoseconds, five consecutive instances are required. If Process A is 
an event process, then one nanosecond represents the elapsed time 
separating two successive occurrences of Process A. To represent an 
elapsed time greater than one nanosecond, it is necessary to separate 
the two occurrences by the appropriate number of instances. (To 
accomplish this, null events may have to be introduced.) 

The format for the synchronic structure of a system is a list of 
declarations, each of which is in one of the following two forms: 

PROCES$_NAME is synchronous with granularity T; 


PROCESS_NAME is asynchronous; 
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The meaning of the first statement is apparent. The second statement 
says that there is no metric for time associated with the sequence of 
instances representing the behavior of PROCESS_NAHE. A single system 
may contain both synchronous and asynchronous processes, and among the 
synchronous processes there may be several distinct granularities* 
There is one restriction, however, when there are multiple 
granularities. We require that for any two granularities T 1 and T 2 , 
either T, is an integer multiple of T 2 or vice versa. This restriction 
is necessitated by the semantics of a synchronic structure. 


4.2 Semantics of a Synchronic Structure 


As we noted earlier, one of the purposes of a synchronic structure 
is to restrict the set of permitted traces. We describe now the form 
that that restriction takes. 

Suppose that A and B are two synchronous processes with 
granularities T A and T 8 , respectively. Assume that T A 2T B and let 
n“T A /T B * This means that there are n instances of Process B for every 
instance of Process A. How can this property be expressed as a 

restriction on traces? The approach adopted is to require each instance 

of Process A to be concurrent with n instances of Process B. This idea 
is illustrated in Figure ^ for the case i a /T e * 5. Notice that there are 
exactly five instances of Process B - b 3> b 4 , b 5 , b 6 and b 7 - concurrent 
with a t . The remaining instances of Process B either precede a, or 
follow a 1 . 

The reader will also note that our requirement does not strictly 
hold for a 0 and a 2 . There are only three instances of Process B - b 0 , 
b 1 and b 2 - concurrent with a 0 , and likewise only three instances of 

Process B - b 8 , b g and b 10 - concurrent with a 2 . This problem, which is 

related to the finite nature of a trace, is purely technical and can be 
remedied by a more precise statement of the requirement. The 
restatement, which will also clear up some other details, is deferred to 
a subsequent paper. 


5.0 LOGICAL SPECIFICATION OF UNIPROCESS SYSTEMS 


In Section 6 we describe a language, called MPL (for Hul t i Process 
Language), for specifying both logical and timing dependencies in the 
context of the system model introduced earlier. Before addressing the 
multiprocess case, however, it is useful to consider first the 
uniprocess case - that is, the case where a system has just a single 
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Legend 

# Process A 
a Process B 


Figure k. A Trace of Two Synchronous Processes 


process. Although the syntax of the languages is essentially the same 
for both cases, the semantics for uniprocess systems is simpler, 
requiring less mathematical apparatus. One valuable benefit cf this 
two-step approach is that it permits us to see how the concepts for 
uniprocess systems generalize in a natural way to multiprocess systems. 

Because we are dealing with systems having a single process, the 
system model can be greatly simplified. A ( uni process ) system is an 
ordered pair <V,5> where Visa set of values and 1 is a set of 
permi tted value sequences, each of which is of finite length. As in the 
multiprocess case, values may be interpreted as states or events, or 
they may simply be left uninterpreted. In addition, the system may be 
viewed as synchronous or asynchronous. 
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5.1 Atesaic Formulas 


URL (for Uni Process Language) is the language for expressing logical 
and timing relationships for uniprocess systems, and, like any language, 
it must have a set of basic building blocks. These are called atomic 
formulas . Although the precise syntax for these formulas is not 
important in the present discussion, each such formula must define a 
predicate on the set of values. The subset of values for which the 
formula Q holds (is true) is denoted Values(Q). For example, if V is 
the set of integers and Q is the formula 3<X<7# where X represents the 
system process, then Values (Q)®{^, 5*6} • 


5.2 Connectives 


UPt is an extension of the language of Boolean expressions. It has 
four basic connectives: the familiar Boolean connectives ‘and 1 and 
'not 1 , the new binary connective 'and^next* and the new unary connective 
'and^next**. The additional connectives ‘or 1 , 'or_next', 'or^next**, 
'implies 1 and ' impl ies_next 1 are defined as abbreviations: 

P or Q for not ( (not K) and, (not Q) ) 


P or_next Q 

for 

not ((not P) and^next (not Q)) 

or_next* Q 

for 

not (and_next* (not Q)) 

P impl ies Q 

for 

(not P) or Q 


P eotpl i es_next Q for 


(not P) or_next Q 


As a notational convenience when writing long expressions, we adopt 
the following shortened forms for the various connectives: 


not - 

and - A 

and^next - A 

and^next* - A 

or - V 

or_next - V 

or^next* - V 

implies - -> 
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imp1ies_next - *> 

Note that since 'andjrext 1 is a binary connective while 'and_next*' is a 
unary connective, no confusion should arise from using the same symbol 
for both connectives. The same observation appi ies to ‘or_next‘ and 
‘or next*'. 


5*3 Concatenation 


In order to define the semantics for UPL, we need some familiar 
concepts from formal language theory. (See Hopcroft and Ullman [ 19 ].) 

If a and 3 are sequences, then «3 denotes their concatenation, x 
denotes the null string, for which the properties Xu *<x and uX*u hold for 
all strings a. If A and B are each a set of sequences, then 

A*B * {apltt is in A and 3 is in B} 

Thus, if A * {ab, bb} and B * {b, a, bab} , then A # B * {abb, aba, abbab, 
bbb, bba, bbbab} . 

If A is a set of sequences, then A°*txj and a ^A 1 * 1 • A for i>0. The 
closure of A, denoted A*, is the set consisting of the null sequence X 
and all f i ni te- 1 ength sequences obtained by concatenating sequences in 
A. Equivalently, 

A* » A 0 U A 1 U A 2 ••• 


5.4 Semantics 


Each formula of UPL ultimately represents a predicate on V* (the set 
of f i ni te- 1 ength value sequences). Thus, the ultimate meaning of a 
formula of UPL is given by the set of value sequences that satisfy the 
formula. In order to define this set, however, we need to introduce two 
intermediate quantities for each formula. For a formula P, In(P) and 
Ex(P), which are both subsets of V*, represent the ‘Included 1 and 
‘Excluded 1 value sequences, respectively, associated with P. In(P) and 
Ex(P) are defined inductively, first for atomic formulas and then for 
formulas constructed using each of the four basic connectives. In what 
follows. Bo (P) denotes In(P) U Ex(P). 
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5*4*1 Meaning of atomic formulas 

Each atomic formula will eventually be interpreted as a predicate on 
value sequences. Recall* however* that initially each atomic formula 
represents a predicate on (individual) values* and that Values (P) 
denotes the set of values that satisfy the atomic formula P. Now 
interpret each value in Values(P) and in V (the set of all values) as a 
sequence of length one. Then, 5 

In (P) « Values (P) 

Ex (P) - V - Values (P) 

In(P) is, thus, the set of those sequences of length one whose (only) 
value satisfies P. Ex(P) is the set of those sequences of length one 
whose (only) value does not satisfy P. 


5*4.2 Meaning of 'not 1 

The connective *not' merely interchanges the included and excluded 
sets for an expression. Thus, 

In (not P) « Ex (P) 

Ex (not P) « In (P) 


5.4.3 Meaning of 'and* 

The definitions of the included and excluded sets for 'P ^nd Q 1 is 
consistent with the usual intuition about *and*: 

In (P and Q) « In (P) fl In (Q) 

Ex (P and Q) * Ex (P) U Ex(Q) 

Thus, a sequence is in In (P and Q) if it is in both In(P) and In (Q) . 

The definition of Ex(P and Q) is motivated by the need to have 
In(P or Q) = In(P) U In(Q) (see below). 

Note that if we stopped at this point without introducing the 
non-classical connectives 'and_next' and *and_next**, we would have the 
semantics of classical logic. Let us call a formula cl ass I cal if it is 
constructed from the set of atomic formulas using only the classical 
connectives 'and 1 , ‘or 1 , ‘not 1 and ’implies 1 . Then for each classical 
formula P, In(P) consists of the set of values that satisfy P in the 
classical sense, while Ex (P) , which is just the set- theoret i c complement 
(with respect to V) of In(P), consists of the set of values th3t do not 


If A and B are sets, then A - B is the set containing those elements 
that are in A but not in B. 


21 







*&/&*** 






satisfy P in the classical sense. Hence, when 'and_next' and 
'and_next*' are excluded, 'and 1 , ‘or 1 , 'not 1 and 'implies 1 can still be 
used in the classical way. 

When "andjiext- 1 and 'andjnext*' do become involved, however, In(P) 
and Ex{P) are no longer necessarily complements of one another, and 
interpreting the effects of the classical connectives on In (P) and Ex(P) 
sometimes requires a little thought. 


5.4.4 Meaning of 'and^next 1 

Expressions involving the phrase 'and next* are common in everyday 
life: "First we'll do this, and next we'll do that." This notion of 

temporal ordering is captured mathematical ly using concatenation. If a 
and 3 are two sequences, then «3 embodies the idea 'a and next 3 '. This 
theme provides the basis for our definition of the included and excluded 
sets for 'P and_next Q 1 : 6 

In(P and_next Q) « In(P)*In(Q) 

Ex (P and_next Q) « Ex(P)-Bo(Q) U Bo(P)-Ex(Q) 

Each sequence in In (P and_next Q) thus consists of a sequence from In(P) 
'and next 1 a sequence from In(Q). The definition of Ex(P and^next Q; 15 
meant to parallel the definition of Ex (P and Q) . Hence, a sequence is 
in Ex (P and_next Q) if it consists of a sequence from 80 (P) followed by 
a sequence from Bo(Q) such that either the first sequence is in Ex(P) or 
the second sequence is in Ex (Q) . 

To illustrate the definitions for 'and_next' # consider the situation 
where In(P)*{a}, Ex(P)«{b,c}, In(Q)»{a,b} and Ex(Q)*{c}. Then 

In(P and_next Q) =* {aa, ab} 

£x{P and_next Q) » {ba, bb, be, ca, cb, cc, ac} 

Note that all the sequences in In(P), Ex(P), Xn(Q) and Ex (Q) are of 
length one, while all the sequences in both In(P and_next Q) and 
Ex (P and_next Q) are of length two. This is an illustration of a 
general property: If all the sequences in In(P) and Ex(P) are of length 

m and all the sequences in In(Q) and Ex (Q) of length n, then all the 
sequences in both In(P and_next Q) and Ex(P and^next Q) are of length 
nv+ n. 


We noted earlier that for the case when P is a classical formula. 

In (P) and Ex (P) are the set-theoretic complements (with respect to V) of 
one another. We now consider some of the ways in which that simple 
relationship breaks down when the connective 'and_next' is introduced. 
Assume P, Q, R and S to be classical formulas throughout the discussion. 


6 Recall that Bo (P) « In(P) U Ex (P) . 
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Now let F represent the formula *P and_next Q* . Since In(F) and Ex (F) 
are not subsets of V t they cannot be set-theoretic complements with 
respect to V.* But they are set-theoretic complements with respect to 
V 2 * In fact, if P 1 ••• P n are all classical formulas and F represents 
the formula , P 1 and_next ••• and_next P n ' , then In (F) and Ex(F) are 
set-theoretic complements with respect to V n . 

Now let F represent the formula *P and (Q and_next R) 1 . Applying 
the above definitions, we have 

In (F) * In (P) n (In (Q) *In (R) ) 

Ex (F) « Ex (P) U (Ex (Q) *Bo (R) ) U (Bo (Q) ■ Ex (R) ) 

Since In(P) contains only sequences of length one and In(Q)*In(R) only 
sequences of length two, In(F) is empty. Ex(F), on the other hand, is, 
in general, non-empty and contains an assortment of sequences of length 
one and length two. There is little that can be said about the 
relationship between In (F) and Ex(F). They are not set-theoretic 
complements with respect to any interesting set. They are, however, 
mutually exclusive. But this is not always the case. 

Let a, b, c, d and e be arbitrary values, and let P, Q, R and S be 
defined such that 


a 

i s 

i n 

In (P) 

b 

I s 

i n 

In (Q) 

c 

i s 

i n 

Ex(Q) 

c 

i s 

i n 

In (R) 

d 

i s 

i n 

Ex (R) 

e 

i s 

i n 

Ex (S) 


Now let F represent the formula 

( (PV (PAQ) ) AQ) A (RV ( (RVS) AS) ) 

(The meanings of ’or’ and 'or_next' are given below.) It is easily 
verified that the sequence abcde is in both In (F) and Ex(F). Although 
this example may seem counter-intuitive, it presents no problem in 
defining the semantics for UPL and, in fact, there is a natural 
interpretation for it (see Section 5.4.11), 


5.4.5 Meaning of 1 and^next*' 

In order to express such temporal relations as ‘’until* 1 , “as long as“ 
and "following", we need the ability to represent for a formula P the 
following infinite expression: 7 

A or P or (P and_next P) or (P and_next P and_next P) or 

The included set for this expression, obtained using the definitions 
already given, is 
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Cx> U In (P) U In (P) *In (P) U In(P) ’ln(P) -In(P) U ••• 
while the excluded set is 

«j> n Ex(P) n Ex (P and_next P) fl Ex(P and_next P and_next P) n ••• 

The first quantity is just (In (P) ) * . while the second quantity reduces 
to the null set. We are thus led to the following meaning for 
•and next* P * • our represention for the above infinite expression: 

In(and_next* P) ■ (In(P))* 

Ex (and_next* P) * 4> 

Notice that for the special case when Pisa classical formula, 

In (and_next* P) is just the set of all value sequences o such that each 
value in a satisfies P. 


5.1*. 6 Meaning of 'or' 

The connectives 'or', 'or_next', 'or_next*', 'implies' and 
'implies next' are all abbreviations for expressions involving the four 
basic connectives 'not', 'and', 'and_next' and 'and_next*'. The 
meanings Of these five additional connectives, therefore, follow 
directly from the preceding definitions. 

For the connective 'or', we have 

In (P or Q) = In (P) U In(Q) 

Ex (P or Q) «= Ex (P) 0 Ex(Q) 

A sequence is thus in In(P or Q) if it is in either In(P) or In(Q). 


5.4.7 Meaning of 'or_next' 

By applying the appropriate manipulations to the meaning of 
'and_next‘, we obtain for 'or_next', 

In(P or_next Q) “ In(P)*Bo(Q) U Bo(P)'In(Q) 

Ex(P or_next Q) = Ex(P)*Ex(Q) 

A sequence is in In(P or_next Q) if it consists of a sequence from Bo(P) 
followed by a sequence from Bo(Q) such that either the first sequence is 
in In (P) or the second sequence is in In(Q). Each sequence in 


7 A denotes the 'null formula'. By convention, In(A)>=’{x} and Ex(.\)*4>. 
<l> denotes the empty set. 
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Ex (P or_next Q) consists of a sequence from Ex (P) 'and next* a sequence 
from Ex (Q) . 

As an illustration, consider the same example we gave for 
'and^next'* where In(P)»{a}, Ex(P)«{b,c}, In(Q)»{a,b} and Ex(Q)*{c}* 
Then 

In(P or_next Q) «* {aa, ab, ac, ba, ca» bb, cb} 

Ex(P or_next Q) * {be, cc} 


5.^.8 Meaning of 'or^next* 1 

The definitions for 'or^next** parallel those for ' and^next*' ; 
In(or_next* P) * 4> 

Ex(° r _next* P) * (Ex(P))* 

For the special case when Pisa classical formula, Ex(or_next* P) 
consists of all value sequences a such that each value in <* satisfies 
'not P‘. 


5.1*. 9 Heading of 'implies* 

The connective 'implies', which is used almost exclusively in the 
context of classical formulas, has a meaning that is consistent with 
that usage: 

In (P implies Q) - Ex(P) U In(Q) 

Ex(P implies Q) « In(P) 0 Ex (Q) 

5. 4.10 Meaning of 1 impl ies_next 1 

In specifying the logical behavior of systems, one repeatedly finds 
the need to express the dependency: "Whenever Behavior 1 occurs, it 

must be immediately followed by Behavior 2," If we assume Behavior 1 to 
be represented by Formula P and Behavior 2 by Formula Q, then, as shown 
below, this dependency can be expressed as ' P implies_next Q* . The 
definitions that permit this interpretation are: 

In(P imp!ies_next Q) * Ex(P)*Bo(Q) U Bo(P)*In(Q) 

Ex(P implies_next Q) « In(P)*Ex(Q) 


As an illustration* consider once again the example given above where 
In(P)»{a}, Ex (P) = {b,c} , In(Q)“{a,b} and Ex(Q)«{c}. Then 


In (P implies^next Q) * {ba, bb, be, ca, cb, cc, aa, ab} 
Ex(P impl i es^next Q) * {ac} 


5.4.11 Satisfaction and Truth 

In the preceding sections, we have shown how to calculate the 
quantities In(P) and Ex (P) for any formula P in UPL. Recall, however, 
that ultimately a formula is to be interpreted as a predicate on V* and 
that the ultimate meaning of a formula is given by the set of value 
sequences that 'satisfy 1 it. We now define, with the aid of Ex (P) , what 
it means for a sequence of values to 'satisfy* a formula P of UPL. We 
select Ex(P), rather than In(P), for the role because we are interested 
in expressing properties that constrain, or restrict, the set of 
permitted value sequences. It is the excluded sequences of a formula 
that provide these restrictions. 

A sequence of values a satisfies a formula P of UPL if and only if a 
contains no member of Ex (P) as a subsequence. 8 Thus, if 3 is in Ex (P) 
and if is an extension of 3 (7 contains 3 as a subsequence), then 7 
cannot satisfy P. To illustrate this idea, consider the example used 
several times earlier in which In(P)={a), Ex (P) “{b,c} , In(Q)*{a,b} and 
Ex(Q)-»{c}. Let F represent the expression *P implie$_next Q' . As noted 
above, Ex(F)*{ac}. A sequence, therefore, satisfies F if and only if it 
does not have ac as a subsequence. Examples of such sequences are: x, 
a, b, c, ca, bb, abc, abab and abbca. Examples of sequences that do not 
satisfy F are: ac, aac, acb, aacc and bbacb. 

The reader will note that because satisfaction is defined using only 
Ex(P), the possibility that In (P) and Ex (P) may not be set-theoretic 
complements or that they may intersect presents no technical problems. 
Some situations do arise, however, that do not exist in classical logic, 
but 'make sense' in the context of our model. For example, if P is a 
formula in UPL, then it is possible for a sequence of values to satisfy 
both P and ^P, o r to satisfy neither P nor -'P. 9 To illustrate, let F 
represent the formula 'P implies_next Q’ where P and Q are classical 
formulas. Because all the sequences in both In (F) and Ex(F) are of 
length two, all sequences of length one satisfy, by default, both F and 
"*F. This is natural. If a formula of UPL expresses a constraint on 
sequences of length n, then we expect all sequences of length less than 
n to satisfy the formula by default. Now consider any formula F for 
which In(F) and Ex (F) are both non-empty. Let a be a member of In (F) 
and 3 a member of Ex(F). The sequence u3 then has subsequences in both 


Sequence a is a subsequence of sequence 3 if and only if there exist 
sequences 7 and 6 such that 3*7«5. 

Do not confuse the statement 'u does not satisfy P' with the 
statement 'u satisfies The first statement says that a has a 

subsequence that is in Ex(P), while the second says that no 
subsequence of « is in Ex(~»P). 


26 





'VwT^rjr- 










In(F) and Ex{F). But since In(F)»Ex( n F) » <xP has subsequences in both 
Ex (F) and ExhF) and hence satisfies neither F nor ^F . This too is 
natural. If a formula of UPL expresses a constraint on sequences of 
length n, then we expect there to be sequences of length greater than n 
that violate the constraints of F in one location and violate the 
constraints of " l F in another location. 

The last order of business in providing the semantics for UPL is the 
notion of •truth'. A formula P of UPL is true (with regard to a given 
system) if and only if every permitted value sequence satisfies P. In 
other words, P is true if and only if no permitted sequence has a member 
of Ex{P) as a subsequence. True formulas thus specify, by restriction, 
the set of permitted value sequences, and they are the mechanism by 
which a logical specification constrains system behavior. 


5*5 Algebraic Properties 


In much of the preceding discussion, we have tacitly made use of 
certain 'algebraic 1 properties of UPL. For example, in writing *P 
and_next P and_next P 1 we assumed that 1 and_next‘ represents, in some 
sense, an associative operator. Let us say that two formulas of UPL are 
'equal 1 if their included and excluded sets are the same. Then the 
following algebraic properties involving the classical operations A, V 
and follow from the above definitions. 


xAx«x and xVx=x 

xAy=yAx and xVy«yVx 

xA (yAz) = (xAy) Az and xV (y Vz) *= (xVy) Vz 

xA(xVy)=x and xV (xAy) *=x 

xA (yVz) = (xAy) V (xAz) and xV (yAz) = (xVy) A (xVz) 
^ (xAy) *“*xV’ , y and ^ (xVy) =^xA“ 1 y 


(idempotence) 
(commutat ivi ty) 
(associ ati vi ty) 
(absorption) 
(di str ibut i vi ty) 
(DeMorgan's Laws) 
(i nvolut ion) 


An algebra satisfying these properties is called a DeHorqan algebra . 

(See Balbes and Dwinger [1], Chapter XI.) The interesting thing about a 
Dettorgan algebra is that it satisfies nearly all the usual properties of 
a Boolean algebra* In fact, it would be a Boolean algebra with the 
addition of the Law of the Excluded Middle: xV-'x-l . 


The properties that involve the non-classical connectives A, V are: 
xA (yAa) * (xAy) Az and xV (y 7z) « (xVy) Vz (associativity) 

n (xAy) ^xV^y and -* (xVy) «^xA^y (DeMorgan's Laws) 
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5*6 Examples of Statements about Uni process Behavior 


Having provided the formal semantics for UPL f we now show how some 
common logical /temporal dependencies can be expressed within UPL. For 
simplicity, we assume in the following examples that P, Q and R are 
classical formulas - that is, formulas constructed from the set of 
atomic formulas using only the connectives 'and 1 , 'or 1 , 'not 1 and 
'implies 1 . In addition, we define T (F) to be an atomic formula that is 
satisfied by all (no) values. 


5.6.1 Example 1 (invariance) 

The simplest assertion that one can make about system behavior has 
the form: "P is true", where Pisa classical formula. From the 

semantics provided above, it follows that P is true if and only if every 
value in every permitted value sequence satisfies P. Therefore, saying 
that P is true is equivalent to saying that P is always true. A 
statement that is always true is commonly called an invariant . 


5.6.2 Example 2 

Consider the statement: 

"P is followed three values later by Q." 

This is a shorthand way of saying: "If a value satisfies P, then the 

third value following this value must satisfy Q." Or expressed a little 
differently: "If a value satisfying P is (immediately) followed by two 

arbitrary values, then the next value must satisfy Q". When stated in 
this way, the dependency is seen to have the same meaning as the 
following two (equivalent) formulas of UPL: 

(P and_next T and_next T) implies^next Q 

P implics_next (F or_next F or^next Q) 


5.6.3 Example 3 (inevitability) 

Consider the statement: 

"Q is inevitable within three values following P." 

In other words: "If a value satisfies P, then at least one of the next 

three values must satisfy Q." Expressed a little differently: "If a 

value satisfies P, then the next value or the next value or the next 
value must satisfy Q." When put this way, the statement has a direct 
translation into UPL: 

P implies_next (Q or_next Q or_next Q) 
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Note the parallel with the second formula in Example 2. Note also that 
this approach to expressing inevitability does not generalize to 
‘unbounded 1 inevi tabi 1 i ty. To express "Q is inevitable following P M 
would require the infinite expression: M P implies_next (Q or_next Q 
or next 


Example 

Consider the statement: 

"Q for three values following P." 

Or equivalently: M If a value satisfies P, then the next value and the 

next value and the next value must all satisfy Q", the obvious 
translation of which is: 

P implies_next (Q and_next Q and_next Q) 

This formula, however, does not precisely capture the intended meaning 
of the above statement. The formula expresses a constraint on value 
sequences of length four (and, by extension, to sequences of length 
greater than four), but places no constraints on sequences of length 
less than four. For example, if the first value of a length-two 
sequence satisfies P, then the formula imposes no restrictions on the 
second value - it may, or may not, satisfy Q. A formula that correctly 
expresses the intended meaning of the above statement is the following: 

P impl ies_next Q 

and 

(P and_next T) implies^next Q 
and 

(P and_next T and_next T) implies_next Q 


5.6.5 Example 5 (following) 
Consider the statement: 


"Following P, Q." 

This is shorthand for: "If a value satisfies P, then all future values 

must satisfy Q". Or put another way: If a value satisfying P is 

followed by a finite number (including zero) of arbitrary values, then 
the next value must satisfy Q." When expressed in this way, the 
statement can be translated directly into UPL as: 

(P and_next (andjiext* T) ) implies_next Q 
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5*6.6 Example 6 (as long as) 

Consider the statement: 

M Fo1 lowing P, Q as long as R." 

This is another way of saying: "If a value satisfies P* then any 
following value must satisfy Q if that value and all intervening values 
satisfy R." Or put another way: “If a value satisfying P is 
(immediately) fol lowed by a finite number (including zero) of 
consecutive values satisfying R v then the last value (in the sequence of 
consecutive values satisfying R) must satisfy Q. M In UPL the statement 
becomes: 

(P and_next (and_next* R) ) impl?es_next (R implies Q) 

5.6.7 Example 7 (until) 

Consider the statement: 

"Following P, Q unti 1 R." 

Which is to say: "If a value satisfies P, then any following value must 
satisfy Q provided that no intervening value satisfies R." Or 
equivalently: "If a value satisfying P is (immediately) followed by a 
finite number (including zero) of consecutive values satisfying ’not R 1 , 
then the next value must satisfy Q." The corresponding formula in UPL 
is: 

(P and_next (and^next* (not R) ) ) implies^next Q 


5.6.8 Example 8 
Consider the statement: 

"Q holds for all odd-numbered values following P." 

Thus, if a value satisfies P, then the first, third, fifth ••• value 
following that value must satisfy Q. This constraint is expressed in 
UPL as: 

(P and_next (and^next* (T and_ next T) ) ) implies^ next Q 

5.6.9 Remarks 

We make two observations about the preceding examples. First, 
except for Example 1, each statement is in the form of an implication 
stating what must be true in the future given some current condition. 
It should be clear, however, that there are analogous statements 
involving past behavior. For example, "Preceding P, Q" is the 
counterpart to "Following P, Q" . Such statements, which are as 
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legitimate as those predicting future behavior, are expressible within 
UPL because the language has no fundamental bias towards either the past 
or the future* 

The second observation about the above examples concerns their 
interpretation when the system process is declared to be synchronous and 
is assigned a granularity. With such a declaration, formulas of UPL 
take on a temporal meaning. Suppose, for example, that the system 
process is declared to be synchronous with a granularity of one 
millisecond. Then the formulas in Examples 2 , 3 and 4 can be 
reinterpreted as follows: 

M P is followed three milliseconds later by Q. u 

"Q is inevi table wi thin three mi 1 1 i seconds following P." 

M Q for three milliseconds following P.“ 

Such is the way in which logical and timing constraints are integrated 
into a single framework* 




MPL (for HultiProcess Language) is the language for specifying both 
logical and timing dependencies in multiprocess systems. It has much in 
common with UPL. Except for the addition of a unary connective (called 
'reverse') , the syntax of UPL is identical to that of UPL. The basic 
connectives 'not', 'and', 'and_next‘ and ‘and_next*‘ are used in the 
same way, while the auxiliary connectives ‘or*, 'or^next 1 , *or_next*, 
‘implies 1 and ' impl i es_next ' are defined as the same abbreviations. 

Like the uniprocess case, the semantics for each formula P of MPL is 
given by the two sets In (P) and Ex(P) which, again like the uniprocess 
case, are defined inductively, first for atomic formulas and then for 
formulas constructed using each of the basic connectives. Furthermore, 
In(P) and Ex(P) retain their original forms - as expressions involving, 
union, intersection and concatenation - when P is constructed using any 
of the original UPL connectives. For example, Ex(P and_next Q) “ 
Ex(P)*Bo(Q) U Bo(P) # Ex(Q) in both the uniprocess and the multiprocess 
case. However, because the formulas of MPL are eventually to be 
interpreted as predicates on (partially ordered) traces rather than 
predicates on (totally ordered) value sequences, it is necessary to use 
a different type of structure within the included and excluded sets for 
a formula P. In the uniprocess case, In(P) and Ex (P) are each a set of 
value sequences, while in the multiprocess case, In(P) and Ex (P) are 
each a set of trace-like objects, called 'templates'. This change from 
sequences to templates entails two modifications to uniprocess 
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semantics: (1) the included and excluded sets for atomic formulas must 

be redefined and (2) the notion of concatenation must be adapted to 
templates. 

The following sections focus primarily on the structure of 
templates, their use in included and excluded sets, and their ultimate 
interpretation as templates' for traces. 


6*1 NPL Syntax 


As in the case of uni process systems, we assume the existence of a 
set of atomic formulas . As above, we are not concerned with the 
particular syntax for atomic formulas, but we do assume that each atomic 
formula Q is associated with a unique process - denoted Process (Q) - and 
represents a predicate on the values belonging to Process (Q)'s type. 

The subset of values in Type (Process (Q) ) for which Q holds (is true) is 
denoted Values (Q) . 

Composite formulas of MPL are constructed from the set of atomic 
formulas using the four basic connectives of UPL - 'not', 'and', 
'and_next* and *and_next* - plus the new unary connective 'reverse* - 
denoted The auxiliary connectives : or* , 'or^next', *or_ next*, 
'implies* and ' impl i e$_next * retain their original meanings as 
abbrevi ations . 


6*2 Templates 


Informally, a 'template* is a directed graph whose vertices are 
instances 10 and whose edges (arrows) come in two types: those labelled 
'next* and those labelled 'last*. Formally, a template is an ordered 
triple <I,N,L> where lisa finite set of instances and where N and L 
are each a set of directed edges on I. Although there are no 
restrictions on the structure of a template, only those templates that 
correspond to partial orders - those without (directed) circuits -will 
be of interest. For a template <I,N,L>, 


Recall that an instance is a triple <p,v,n> where p is a process, v 
is a value in Type(p), and n is a positive integer. 


10 




1 

i 

i 

f 
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Instances (<I,N,L>) » I 

Next (<I,N,L>) - N j 

1 

Last (<I,N,L>) - L ] 

The head (tall ) of a template is the set of those instances that have no 
emergent (entrant) edges. The null template is denoted by k. 

To illustrate these ideas, let T be the template depicted in Figure 5> 

Then j 


Instances (T) 

“ {Xq» 

^ 1 * *2 * *3 9 

Head (T) 

" {Xg , 

X 7 } 

Tail (T) 

“ {x 0 . 

X,} 

Next (T) 

* (<X 0 , 

,X 2 >, <X 1 ,Xg> 

Last (T) 

* {<X 4 , 

,X 5 >, <X 5 ,X 6 > 


4» X 5 , Xg» 


<x 2 , X 4 ^ , 
<x 5 ,x 7 >) 


X 7> 


<x 3 ,x 4 >} 
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6*3 A Partial Order on Templates 


In defining In(P) and Ex (P) for a formula P of MPL, we will make use 
of a partial order on templates which is intended to capture the idea of 
one template being a 'simpler 1 or less ‘restrictive* version of another* 
The ordering depends on the notion of a 'morphism* between two 
templates. 


Let T 1 and T 2 be templates* A mapping 4> from Instances (T^ to 
Instances (T 2 ) is called a morph i sm from T t to T 2 if for all x,y in 
Instances (T^ , 


Process (x) * Process d (x) ) 

Value(x) « Value (x) ) 

<x,y> in Next(T t ) =»> < 4 * (x) # 4» (y) > in Next(T 

<x,y> in LastfTj) s > <*1» (x) ,<My) > in Last(T 
x in Head (T t ) **> ^ (x) in Head (I 2 ) 

x in Tail (T t ) »> * (x) in Tail (T 2 ) 


2^ 

2 ^ 



4 


i 


1 S 
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Figure 5* A Template 
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If the mapping 4» is one-to-one, then the morphism is also said to be 
one-to-one, 11 

We now use the notion of morphism to define the partial order £ on 
templates. 12 If T 1 and T 2 are templates, then T^T,, if and only if at 
least one of the following conditions holds: 

(1) T t and J 2 are both the null template. 

(2) T 1 and T 2 are both non-null and there exists a one-to-one 
morphism from T 1 to T 2 . 

(3) T 1 and T 2 are both non-null and there exists a morphism from T 1 
to T 2 but no morphism from T 2 to 

We note first that the null template \ is isolated by £ from all other 
templates. Condition 2 says, in effect, that there is an exact copy 
(except for instance numbering) of T 1 embedded in I 2 and that the head 
(tail) of this copy is contained in the head (tail) of T 2 , Condition 3 


11 A mapping 4* is one-to-one if distinct elements in the domain of 4> 
have distinct images under 4'. 


In claiming that ^ is a partial 
be identical if they differ onl 


order, we consider two templates to 
in their instance numbers. 


3 ^ 
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says that there is a ‘collapsed 1 version of embedded in T 2 and that 
the head (tail) of this version is contained in the head (tail) of T 2 • 
Condition 3 also requires that there be no similar version of T 2 
embedded in T r 

To illustrate the concept of template ordering, consider the three 
templates in Figure 6. Assume that like-named instances in separate 
templates have the same process and value. Assume, furthermore, that 
Process (x 0 ) “Process (x 0 ‘) and that Value (x 0 ) “Value (x 0 1 ) Notice that an 
identical copy of T 1 is embedded in T 2 and that the head (tail) of this 
copy is contained in the head (tail) of T 2 . Thus, T^T 2 h/ Condition 2. 
(This relationship also follows from Condition 3 if and x 2 in T 2 
differ in either process or value,) Now notice that there is a 
'collapsed' version of T 2 embedded in T 3 and that the head (tail) of 
this version is contained in the head (tail) of T 3 . Notice also that 
there is no similar version of T 3 embedded in T 2 (assuming that x t and 
x 2 differ in either process or value). Hence, T 2 £T 3 by Condition 3* 

To help motivate the last requirement in Condition 3* suppose that 
x 1 and x 2 in template T 2 of Figure 6 have the same process and value. 
There is then a morphism from T 2 lo Ij. Now if the last requirement in 
Condition 3 were omitted, it would follow that T 2 £T t . But because T^T 2 
by Condition 2, the antisymmetry property of < would be violated. 

Hence, the need for the last requirement in Condition 3* 


6.1* Concatenat -on of Templates 


Concatenation of templates is analogous to concatenation of 
sequences. If T. and T 2 are templates, then T 1 *T 2 ** <I,N,L> where 13 

I * Instances (T^ U Ins tances (T 2 ) 

N « Next (Tj) U Next(T 2 ) U (Head(T t ) XTai 1 (T 2 )) 

L « Last (T,) U Last (T 2 ) 

T ^ * T 2 is thus obtained by connecting the head of T t to the tail of T 2 
with a set of 'next 1 edges. 

As an illustration of concatenation, consider the two templates T 1 
and T 2 in Figure 7 * T t consists of ; he instances x 0 , x t , x 2 and x 3 and 
the two edges connecting those instances. T 2 consists of the instances 
x 4* x 5 » x e an d x 7 anc * the three edges connecting those instances. T t # T 2 
is the composite graph obtained by connecting T 1 to T 2 with the two 
edges <x 2 ,x 4 > and <x 3 ,x 4 >, which are indicated by dashed lines. 


13 X denotes Cartesian product. 
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Figure 6. Three Ordered Templates 
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Templcrte T 1 Template T 2 


Figure 7* Concatenating Two Templates 
6.5 Well-Structured Sets of Templates 


As already noted, In(P) and Ex (P) , for a formula P of HPL, will be 
definea as sets of templates. These sets will turn out to have two 
important properties: 'upward closure 1 and the 'minimality condition'. 

Let X be a set of elements partially ordered by <. X is said to be 
upward 1 y closed (with respect to 5) if 

x<y and x in X => y in X 

X satisfies the minimality condi tion (with respect to <) if for each 
element y in X there exists a minimal element x of X such that x£y. 15 
When X is both upwardly closed and satisfies the minimality condition, 
we say that it is wel 1 structured . An important property of a 
well-structured set X is that it can be characterized by its set of 
minimal elements - denoted Hin(X). 

The following are four important results relating to well-structured 
sets of templates. 


PROPERTY 1. If T, and T 2 are wel 1 -structured sets of templates, then 
*i^ 2 * ar| d I’i’Tj ar ® also we I 1 -structured sets of templates. 


In other words, the operations of union, intersection and concatenation 
preserve wel i-structuredness. 


15 Note that a minimal element - unlike a minimum element - need not be 
unique. A set may have more than one minimal element. 
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PROPERTY 2. If T, and T 2 are well-structured sets of templates, then 
Hin (T 1 UT 2 ) - MinCMind,) U Min(T 2 )) 


Thus, to find the minimal templates of T,UT 2 we need only look for the 
minimal templates in Hind,) U Min(T 2 ). 


PROPERTY 3 • If T, and T 2 are wel 1 -structured sets of templates, then 
Hind,nT 2 ) * Hin(A) where A is the set of templates T for which there 
exist templates T, and T 2 such that 

• T, is in Hind,) and T 2 is in Min(T 2 ) 

• T 1 ^ T by morphism and T 2 £ T by morphism $ 2 

• Each instance in T is the image under of an instance in T 1 or 
the image under * 2 of an instance in T r 

• Each 'next 1 (’last 1 ) edge in T is the image under 4» 1 of a 'next* 
(’last*) edge in T, or the image under of a 'next* (’last 1 ) 
edge in T r 

Property 3 says something non-obvious. It says that to find the minimal 
templates of T,RT 2 we do not look for the minimal templates in Min(T,) H 
Hin(T 2 ). Instead, we look among the templates formed by 'merging 1 a 
template from Hind,) and a template from Hin(T 2 ). 


PROPERTY If T, and T 2 are we 1 1 -structured sets of templates, then 
Hi n (T t *T 2 ) « Hin (Mind,) *Hin(T 2 )) 


The minimal templates of T,*T a can, thus, all be found in 

Hind,) * Hin d 2 ) • 


6.6 Semantics 


Each formula of HPL will ultimately represent a predicate on the set 
of traces. Thus, the ultimate meaning of a formula in HPL is given by 
the set of traces that satisfy the formula. However, as in the case of 
UPL, we need first to introduce the intermediate quantities In(P) and 
Ex (P) for each formula P of HPL. For UPL, these quantities were sets of 
sequences, but for HPL they are sets of templates. As with UPL, In (P) 
and Ex(P) are defined inductively, first for atomic formulas and then 
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for formulas constructed using each of the five basic connectives. 
(Recall that we now have an additional basic connective, 'reverse'.) 

For all cases, In(P) and Ex(P) will be wel l-structured sets of 
templates. The definitions of these two quantities for the case when P 
is an atomic formula will insure that the property is met for the basic 
bui lding blocks of HPL. The definitions of In(P) and Ex(P) for 
composite formulas will all be expressed in terms of the operations of 
union, intersection and concatenation, each of which preserves 
well-structuredness (Property 1). By having the included and excluded 
sets of all formulas well-structured, we are able to understand the 
meanings of the various connectives in terms of their effects on minimal 
templates. 


6.6.1 Meaning of atomic formulas 

Let P be an atomic formula. P, therefore, has associated with it a 
process - denoted Process (P) - and a set of values - denoted Values (P). 

Let V * Type (Process (P) ) . For the uniprocess case, In(P) is defined as 
the set of those sequences of length one whose (only) value is in 
Values(P). Ex(P) is defined as the set of those sequences of length one 
whose (only) value is in V-Values(P). 

For the multiprocess case, In(P) is the set of all those templates T 
for whicn there exists an instance x such that 

• Process (x) « Process (P) 

• Value(x) is in Values (P) ! 

• <{x} < T 

In other words, In(P) is the set of all those templates T that have 
embedded within them an isolated instance x such that Process (x) * 

Process(P) and Value(x) is in Values(P). (Note that x is in both the 
head and tail of T.) From the definition it follows that In(P) is well 
structured and, therefore, is characterized by its minimal templates. 

These are easily described. They are all templates of the form 
<{x} where Process (x) 33 Process (P) and where Value (x) is in 

Values (P). These minimal templates are in one-to-one correspondence 
(ignoring instance numbers) with the length-one sequences that define 
In(P) for the uniprocess case. 

Ex (P) in the multiprocess case is the set of all those templates T , 

for which there exists an instance x such that 

• Process (x) « Process (F) 

• Value(x) is in V-Values(P) 

• <{x} £ T 


% 
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Ex(P) is, thus* the set of all those templates T that have embedded 
within them an isolated instance x such that Process (x) » Process (P) and 
Value(x) is in V-Values(P). Like In(P), Ex(P) is wel 1 -structured and 
its minimal templates are easily described. They are all templates of 
the form <{x}*4>*4>> where Process (x) » Process (P) and where Value (x) is 
in V-Values (P) . 


6.6.2 Meaning of 'not 1 

As in the uniprocess case, the connective 'not' simply interchanges 
the included and excluded sets of an expression. Thus* 

In (not P) * Ex (?) 

Ex (not P) « In (P) 


6.6.3 Meaning of 'and* 

The definitions of the included and excluded sets for 'P and Q* have 
the same forms used for the uni process case: 

In (P and Q) - In (P) H In(Q) 

Ex (P and Q) «' Ex (P) U Ex (Q) 

Thus, a template is in In(P and Q) if it is in both In(P) and In(Q), and 
is in Ex(P and Q) if it is in either Ex (P) or Ex(Q). To understand 
these definitions and to see how they differ from the ones given earlier 
for UPL, let us look at the definitions in terms of minimal templates. 

Suppose that P and Q are atomic formulas. Then the minimal 
templates in In(P), In(Q), Ex (P) and Ex (Q) are all of the form 
<{x},<fr,<i». From Property 3 » it follows that Min(In(P and Q) ) contains 
two classes of templates: 

(1) those in Min(In(P)) fl H i n (I n ) 

(2) those of the form <{x , y} such that <{x}, <$>,<$» is in 

M i n (I n (P) ) but not Min (In (Q) ) and <{y},«i>,4» is in Min(In(Q)) but 

not Min (In (P) ) 

In analyzing these classes, two cases need to be considered: 

Process (P) « Process (Q) and Process (P) * Process (Q) . When Process (P) « 
Process(Q), the templates in M i n (In (P) ) fl M i n (In (Q) ) are in one-to-one 
correspondence (ignoring instance numbers) with the values in Values (P) 
fl Values (Q) * This corresponds to the classical, uniprocess case. The 
templates in the second class above, however, represent a divergence 
from the classical, uniprocess view. 16 When Process (P) * Process (Q) , 
these templates are in one-to-one correspondence with pairs of values 
{x,y} such that x is in Values (P) -Values (Q) and y is in 
Values (Q) -Values (P) . (Such 1 none 1 ass i ca 1 1 templates turn out to be 
useful in expressing certain logical dependencies.) For the case above 
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when Process (P) # Process (Q), the templates in the second class are the 
only templates in Min(In(P and Q)) since H i n (In (P) ) fl M I n (In (Q) ) is 
empty. These templates are all templates of the form <{x,y) ,4>,4» such 
that <{x},4>,4» is in Min(In(P)) and <{y},4>,4» is in Hin(In(Q)). 

The situation regarding Ex(P and_next Q) is considerably simpler 
than that for In(P and_next P) . From Property 2, we see that 

Hi n (Ex (P and Q)) * Min(Ex(P)) U Hi n (Ex (Q) ) 

(for both atomic and non-atomic formulas). Thus, the definition of 
Ex(P and next Q) for MPL corresponds completely to the definition for 
UPL. 

Having considered the case when P and Q are both atomic, let us 
consider a second special case. Suppose that the templates in In(P) and 
In (Q) are Independent in the sense that no instance appearing in a 
template of In(P) has the same process and value as an instance 
appearing in a template of In(Q). From Property 3. it follows that 
Min(In(P and Q) ) « Min(A) where A is the set of composite templates 
obtained by 'juxtaposing' a template from In(P) with a template from 
In (Q) . For example, if Min (In (P) ) consists of the single template shown 
in Figure 8(a), if Min(In(Q)) consists of the single template shown in 
Figure 8(b) and if x 0 and x 1 differ from x 2 and x 3 in either process or 
value, then Min (In (P and Q) ) consists of the compos i te template shown in 
F igure 8 (c) . 


6.6.** Meaning of 'and^next* 

The meaning of 'and_next‘ in the context of MPL parallels the 
definition given earlier for UPL. There is no change in the expressions 
defining the included and excluded sets but concatenation now applies to 
templates instead of sequences. Hence 

In(P and_next Q) ■ In(P)*In(Q) 

Ex(P and_next Q) * Ex(P)*Bo(Q) U Bo(P) # Ex(Q) 

Each template in In(P and_next Q) thus consists of a template from In(P) 
'and next* a template from In(Q). A template is in Ex (P and_next Q) if 
it consists of a template from Bo (P) ‘and next* a template from Bo (Q) 
such that either the first template is in Ex (P) or the second template 
is in Ex (Q) . 

As we did for 1 and 1 , let us consider the special case when P and Q 
are both atomic. The minimal templates in In(P), In(Q), Ex (P) and Ex(Q) 
are then all of the form <{x},4>,4>>. From Property *4, it follows that 
the templates in Min (In (P and^next Q) ) are all those with the structure 
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This departure from UPL changes the meanings of certain formulas 
representing invariants (see' "ect ion 6.8.1). 




(o) Template 1 



(b) Template 2 



(c) Composite Template 


Figure 8. Juxtaposing Two Templates 


<{x,y}, {<x,y>}, 4>> sucn that <{x},4>,4» is in Min(In(P)) and <{y},$ f <i» 
is in Min(In(Q)). It also follows that the templates in 
M i n (Ex (P and^next Q) ) are all those with the structure <{x,y}, (<x,y>}» 
4>> such that either (1) <{x},4»,<l>> is in Min(Ex(P)) and <{y},4>,4>> is in 
Min(Bo(Q)) or (2) <{x] is in Min(Bo(P)) and <{y} ,<fr,4>> is in 

Min(Ex(Q)). As an illustration, let Min(In(P)) consist of the two 
s i ng l e- i nstance templates shown in Figure 9(a), Mi n (Ex (P) ) the 
single-instance template in Figure 9(b), Min(In(Q)) the two 
s i ngl e- i nstance templates in Figure 9(c), and Min(Ex(Q)) the 
si ng l e- i nstance template in Figure 9(b). Then Min(In(P and_next Q) ) 
consists of the four single-edge templates in Figure 9 (o) and 
Min(Ex(P and_next Q) ) the five single-edge templates in Figure 9(f)* 

Note the parallel with the UPL example in Section $.h.h* There, the 
elements of In(P and_next Q) and Ex (P and_next Q) are value sequences of 
length two. Here, the elements of Min(In(P and_next Q) ) and 
Min (Ex (P and_next Q) ) are templates, each consisting of two instances 
connected by a 'next 1 edge. 

The principles illustrated for the case when P and Q are both atomic 
extend in a stra i ghtforward way to the case when either P or Q is 
non-atomi c . 

6.6.5 Meaning of ‘and^next* 1 

As in the uniprocess case, there is a need to represent the infinite 
f ormu l a : 

A or P or (P and^next P) or (P and_next P and_next P) or 
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• x 2 

-(b) Templates In Min(Ex(P)) 

• x 5 • x 4 

(c) Templates in Min(ln(0)) 



As before, the included set for this formula is given by the infinite 
express i on 

M U In (P) U In (P) * In (P) U In (P) -In (P) -In (P) U ••• 

while the excluded set is given by 

<i> fl Ex(P) fl Ex (P and_next P) fl Ex(P and_next P and_next P) fl * * * 

The first quantity is still just (In(P))* f while the second quantity 
still reduces to the null set* Hence, the expressions defining the 





included and excluded sets for *and_next* P 1 , which represents the above 
infinite formula, remain the same: 

In(and_next* P) « (In(P))* 

Ex (and_next* P) * 

For the special case when P is an atomic formula, Min(In(and_next* P)) 
is just the set of all 1 linear 1 templates whose instances belong to 
In(P) and whose edges are labelled with 'next*. 


6.6.6 Meaning of ‘reverse 1 


Although a template is defined as having two types of edges, ‘next* 
and 'last 1 , the discussion so far has focused only on the first type. 

To see how ‘last* edges enter the picture, consider what would happen if 
all the arrows in a trace were reversed. This is equivalent to 
reversing the past and future. If Instance x precedes (follows) 

Instance y in the original trace, then x follows (precedes) y in the 
reversed trace. Moreover, if x is the last instance of Process X 
preceding y in the original trace, then x is the next instance of 
Process X following y in the reversed trace. Similarly, if x is the 
next instance of Process X following y in the original trace, then x is 
the last instance of Process X preceding y in the reversed trace. As an 
illustration, consider the two templates ir, Figure 10. Each is the 
reverse of the other. Observe that a Q precedes b 3 in the left trace but 
follows b 3 in the right trace. Note also that a 3 is the next instance 
of Process A following b t in the left trace but is the last instance of 
Process A preceding b 1 in the right trace. 

These observations motivate the definitions for the 'reverse' 
connective, whose purpose is to reverse the 'polarity' of a formula P of 
MPL. This polarity reversal is accomplished by performing a simple 
transformation on each edge in each template of In(P) and Ex (P) . If we 
take a 'next' edge from Instance x to Instance y to mean intuitively 
that y is a next instance following x, and if we take a 'last' edge 
from x to y to mean intuitively that x is a last instance preceding y, 
then it is clear from the above discussion that the appropriate 
transformation is: 


x next y — > y last x 

x last y --> y next x 

These transformations are reflected in the following definitions for 
' reverse P ' . 17 

In(reverse Q) * {<I,L" 1 ,N* 1 >I<I,N,L> is in In(Q)} 

Ex (reverse Q) « {<1 , L" 1 !<I ,N # L> is in Ex(Q)} 


As an illustration of these definitions, suppose that the template 
depicted in Figure 5 on page 3*+ is in In(Q). Then the 'reversed' 





Legend 

• Process A 
Q Process B 


Figure 10, A Trace and its Reverse 


template shown in Figure 11 is in In(reverse Q) . To construct the 
template of Figure 5 *n the first place* let P Q *** P 7 be atomic 
formulas such that Process (x^) * Process (P ^ ) and ValueUj) is in 
Va lues (P ^ ) for 0£i^7* The template is then contained in In(Q) where Q is 
the formula: 

((P 0 and_next P 2 ) and (P 1 and_next P 3 ) ) and_next 

(reverse ( (P G and P 7 ) and_next P 5 and_next P 4 ) ) 


6 . 6.7 Meanings of auxiliary connectives 

The connectives 'or', *or_next', ‘or_next* 1 * ‘implies 1 and 
' i mpl i es_next * are all abbreviations for expressions involving the four 
basic connectives r not‘, ‘and 1 , 'and_next' and * and_nex t* 1 . The 
meanings of these additional connectives, therefore, follow directly 
from the preceding definitions. We list here those meanings and refer 
the reader to the uniprocess discussion for a further elaboration. 


In (P or Q) * In (P) U In (Q) 
Ex (P or Q) « Ex (P) fl Ex (Q) 


R* 1 denotes the converse of the binary relation R. <x,y> is in R*" 1 
if and only if <y,x> is in R. 
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Figure 11. A Reversed Template 



In (P or_next Q) « In(P)-Bo(Q) U Bo(P)*In(Q) 

Ex (P or_next Q) ** Ex(P)*Ex(Q) 

In(or_next* P) * <1> 

Ex (or_next* P) - (Ex (P) ) * 

In (P implies Q) = Ex (P) U In(Q) 

Ex (P implies Q) * In(P) fl Ex (Q) 

In (P impl i es_next Q) - Ex(P)*Bo(Q) U Bo(P)-In(Q) 

Ex (P impl ies_next Q) «' In(P)*Ex(Q) 

6.6.8 Satisfaction and Truth 

In defining the semantics for UPl, we said that a sequence of values 
a ’satisfies* a formula P if « contains no member of Ex (P) as a 
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subsequence. A parallel notion is used for MPL. The definition here is 
stated not in terms of a value sequence containing a subsequence, but in 
terms of a trace having a template that * f i ts 1 it. 

A template T fits a trace 2 if there exists a mapping 4* from 

Instances (T) to Instances (2) such that for all x,y in Instances (T) , 

• Process (x) » Process (4* (x) ) 

• Value (x) « Value (4»(x)) 

• <x,y> in Next(T) *> 4> (y) is the next instance of Process(y) 

following 4*(x) within 2 

• <x,y> in Last(T) *■> 4> (x) is the last instance of Process (x) 

preceding 4> (y) within 2 

Consider the template, trace and mapping 4* (indicated by dashed lines) 
depicted in Figure 12. Assume that like-named instances in the template 
and trace have the same process and value. Thus, the process and value 
of a 2 in the template and the process and value of a 2 in the trace are 
the same- Now observe that for each 'next 1 edge <x,y> in the template, 

4> (y) is the next instance of Process (y) following 4* (x) within the 
template. Specifically, a 3 is the next instance of Process A following 
s 2 , and a 3 is the next instance of Process A following Notice also 

that for each Mast 1 edge <x,y> in the template, 4* (x) is the last 
instance of Process (x) preceding 4* (x) within the template. In 
particular, b Q is the last instance of Process B preceding a 2 . We 
conclude that the template fits the trace. 

Using the notion of a template ‘fitting 1 a trace, we define the 
concept of satisfaction. A trace Z satisfies a formula P of MPL if and 
only if there is no template in Ex(P) that fits Z. A formula P of MPL 
is true (with respect to a given system) if and only if every permitted 
trace satisfies P. 

Justification for our practice of using the minimal elements of a 
set of templates to represent that set is provided by Property 6, which 
is a direct consequence of Property 5* 
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PROPERTY 5* Let T 1 and T 2 be templates and let Z be a trace. Then 
T 1 5T 2 and T 2 fits 2 °> T t fits Z , 

PROPERTY 6. A trace Z satisfies a formula P of MPL if and only if there 
is no template in Min(E-x(P)) that fits Z. 
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Legend 

* Process A 
a Process B 


Figure 12. Fitting a Template to a Trace 
6.7 Algebraic Properties 


All the algebraic prope*ties listed for UPL carry over to MPL. 

Thus, the operations of *not‘, 'and* and 'or* form a DeMorgan algebra on 
the formulas of MPL (in the sense described above). Moreover, 

*and_next f and 'or_next' are associative and satisfy DeMorgan's Laws. 


6.8 Examples of Statements about Multiprocess Behavior 


MPL is capable of expressing a broad range of complex logical and 
timing dependencies. An attempt to delineate the expressive power of 
MPL, however, is beyond the present scope. We limit ourselves instead 
to discussing how the examples given earlier for UPL translate to the 
mul t i process case. 

6.8.1 Invariance 

An ? nvar iant (in both the uniprocess and multiprocess case) is a 
true formula constructed from atomic formulas belonging to a single 
process using only the connectives 'and', ‘or* and ^ot 1 . For the 
uniprocess case, the meaning of an invariant Q (interpreted as a true 
formula) is strai ght forward: Every value in every permitted value 



sequence must satisfy Q. For the mul ti process case, there is a slight 
variation. 


In giving the meaning earlier for the connective ‘and 1 , we observed 
that when P and Q are both atomic formulas belonging to the same 
process, In(P and Q) contains certain templates that have no analog in 
the uni process case. These nonclassical templates do not affect the 
interpretation of *P and Q* since it is Ex(P and Q) - not In(P and Q) - 
that determines which traces satisfy the formula. The situation is 
reversed, however, for the formula 'P or Q 1 because the nonclassical 
templates now appear in Ex(P or Q) . Suppose, for example, that P and Q 
are atomic formulas belonging to Process A and that v Q , v t , v 2 and v 3 
are the values of A‘s type. Suppose, furthermore, that : 18 
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The si ngle- i nstance template {v 3 } in Hin(Ex(P or Q) has a counterpart in 
the uniprocess case* but the two-instance template {v 1 f v 2 } has no such 
counterpart. Let us consider what each template says. The first says 
that Process A can never take on the value v 3 in a permitted trace. The 
second says* in effect, that Process A can never take on the values v t 
and v 2 in, the same permitted trace . 


A little reflection reveals the difference in interpreting the 
formula 'P or Q‘ for the uniprocess and multiprocess cases. For the 
uniprocess case, *P or Q* means that 'P or Q* holds tor all values of 
Process A in a permitted value sequence. For the multiprocess case, 

'P or Q' means that either P holds for all values of Process A or Q 
holds for all values of Process A in a permitted trace. (This 
difference in interpreting the connective ‘or 1 e/tends to the case when 
P and Q are non-atomic formulas.) 


Since only one process is being considered and since the templates 
under discussion contain no edges* we represent each template by the 
values associated with its instances. 
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6.8.2 Other Examples 

Examples 2 through 8 in Section 5*6 carry over to the multi process 
case with little change. One difference applies to the formulas in 
Examples ?» 4. 5 and 8. Since we are no longer dealing with just a 
single process* the atomic formula T* which is universally true in the 
uniprocess case* must be replaced by an atomic formula that is 
associated with a particular process. Thus* in Example 2* the atomic 
formula T must be replaced by T A where A is the process associated with 
either the atomic formula P or the atomic formula Q. T A is satisfied by 
all the values in Type(A). 
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6.9 Extended HPl 
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Although the five basic connectives and five auxiliary connectives 
of HPL provide a concise and powerful set of primitives for specifying 
multi process behavior, it often awkward to express certain relationships 
in terms of these primitives alone. For this reason, we permit 
higher-level constructs to be introduced. Some suggested ones are the 
following: (Their translation into standard formulas of HPL should be 

apparent from the discussions in Sections 5.6 and 6.8.) 

• P followed N timejjnits later_by Q. 

• Q inevi table^wl thi n N time_jjnits following P. 

• Q for N time_units following P. 

• Following P, Q. 

• Following P, Q as_long_as R. 

• Following P, Q until R. 

• Following P, Q repeated_every N time^units. 


6.10 Format for Logical Specifications 


«r 


Each of the first three components of a system specification - type 

declarations, process declarations and synchronic structure - have a 

syntax that either is borrowed directly from the Ada programming 
language or is adapted from Ada. That convention is followed again for 

the logical specification. The format for a logical specification is: 
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specification SYSTEHJJAHE is 

declarationl; 

declaration2; 

declarations* 

begin 

HPL statementl; 

HPL statement2; 

HPL statement3; 

end; 

Each declaration, which has the form of an Ada object declaration, 
provides a variable, universally quantified over a specified type, for 
use in the MPL statements. 


7,0 SPECIFICATION EXAMPLE: THE ALTERNATING-BIT PROTOCOL 


The a 1 ternat i ng-bi t protocol [3] [L] [153 [22] [233 provides a 
simple mechanism for achieving reliable communication over an unreliable 
channel. We consider the simplified case in which a 'source 4 accepts 
'messages 4 for transmission to a 'destination 4 . To each accepted 
message, the source attaches a 'bit' and then transmits the resulting 
'packet* repeatedly until an acknowledgement with the same bit is 
received. After such an acknowledgement, the source accepts a new 
message for transmission but this time the bit attached to the message 
is reversed {hence the name of the protocol). 

Seven asynchronous, event processes are used to model the source, 
destination and initializer: 

$GURCE_INPUT - input port for messages 

TRANSMISSIGN_ACK - acknowledges transmission of message 

SOURCE_SEND - transmitting port for packets 

SOURCE_RECEIVE * receiving port for acknowledgement bits 

DESTINATION_RECEIV£ - receiving port for packets 

DESTINATION_SEND - transmitting port for acknowledgement bits 

DESTINATI0N_0UTPUT - output port for messages * 
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INITIALIZER - initializes source and destination 

We present the formal specification of the alternating-bit protocol in 
terms of the constraints imposed on these seven processes. The next 
four sections contain, respectively: type definitions, process 
declarations, synchronic structure and logical specification. 


7.1 Type Definitions 


type HESSAGE_TYPE is INTEGER; 

type PACKET_TYPE is 
record 

MESSAGE: MESSAGE_TYPE; 

BIT: BOOLEAN; 
end record; 

type ACKNOWLEDGE_TYPE is BOOLEAN; 
type INITIALIZE_TYPE is (INIT) ; 


7.2 Process Declarations 

SOURCE_INPUT is event process of MESSAGE_TYPE ; 19 
TRANSKISSIPN_ACK is event process of ACKNOWLEDGE_TYPE; 
SOURCE_SEND is event process of PACKET_TYPE ; 
SOURC£_RECEIVE is event process of ACKNOWL£DGE_TYPE ; 
DESTINATION_RECEIVE is event process of PACKETJTYPE; 
DESTINATION_SEND is event process of ACKNOWLEDGE_TYPE ; 
DESTINATION_OUTPUT is event process of MESSAGE_TYPE; 
INITIALIZER is event process of INITIALIZE_TYPE ; 


19 In addition to the values in its type, we assume that each event 
process may also take on the value NULL. NULL is distinct from all 
other values in a type and is used to indicate the absence of all 
(non-nu) 1 ) va 1 ues . 
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7.3 Synchronic Structure 

SOURCE_INPUT is asynchronous; 
TRANSMISSION_ACK is asynchronous; 
SOURCE_SEND is asynchronous; 
SOURCE_RECEIVE is asynchronous; 
DESTINATION_RECEIVE is asynchronous; 
DESTINATION_SEND is asynchronous; 
DESTINATION_OUTPUT is asynchronous; 
INITIALIZER is asynchronous; 


7.4 Logical Specification 


specif icat ion ALTERNATING jnTJ>ROTOCOL is ; . 7 

MSG: MESSAGE TYPE; 

BIT: ACKNOWLEDGEMENT JTYPE; 

i • 

begin j 


Fol lowing 

SOURCE_INPUT/=NULL, 

SOURCE_INPUT=NULL 
unt i 1 

TRANSMISSION J\CK/=NULL; 

'• A new message is not given to the source until 
- the preceding message is acknowledged, 20 


20 A double dash is the Ada convention for a comment. 
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, Following 
INITIALIZER-INIT » 

$0URCE_SEND*NULL 
unt i 1 

S0URCE_INPUT/-NULL; 

Following initialization, no packets are 
sent before the first message is sent* 


INITIALI2ER*INIT 

and_next 

(and_next* SOURCE_INPUT-NULL) 
and_next 

S0URCE_INPUT«MSG 
impl i es_next 

S0URCE_S END .MESS AGE-MSG and S0URCE_SEND.BIT-0; 

The bit of the first packet sent following 

initial Nation is 0. 


Fol lowing 

SOURCE SEND .MESSAGE-MSG and SOURCE SEND .BIT-BIT, 

SO tJRT-E^S END .MESS AG E-MSG and $3URCE~SEny .BIT-BIT 
unt i 1 

S0URCE_RECEIVE-BIT; 

A packet is sent repeatedly until appropriate 
acknowledgement is received. 

S0URCE_S END. MESS AG E=MSG and SOUR CE^SEND .BIT-BIT 
and_next 

SOURCE_RECEIVE=BIT, 
imp I i es_nex t 
TRANSMISSI0N_ACK-1 ; 

When a packet is acknowledged, the transmission of 
the message is acknowledged. 


Following 

$0URCE_SEND. MESSAGE^MSG and S0URCE_SEND .BIT-BIT 
and_next 

S0URCE_RECEI VE-BIT, 

source“send-null 

a$_Jong as 
S0URCE_INPUT*NULL; 

Once a packet is acknowledged, no new packets 
are sent before a new message is provided. 
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SOURCE_SEND.BIT»BIT 

and_next 

(and_next* SOURCE_SEND-NUll) 
and next 

SOURCEJWPUT-MSG 

implies_next 

SOURCE_SEND.MES$AGE*MSG and SOURCE_SEND.BIT« (not BIT); 

— The bit for a new packet is alternated. 


Fol lowi ng 
INITIALIZER-INIT, 

DESTINATION_OUTPUT=NULL and DESTINATION_SEND*NULL 
as_long as 

DESTlNATION_RECEIVE*»NULl; 

— No messages are received and no acknowledgments 

— are sent before the first packet following 

— initialization is received. 


INITIALIZER=INIT 

and_next 

(and_next* DESTINATION_RECEIVE=NULl) 
and_next 

DESTlNATION_RECEIVE.HESSAGE=HSG and DESTINATION_RECEIVE . BIT=0 
implies_next 

OESTINATION_OUTPUT=HSG and DESTINATI0N_SEND=O; 

If the first packet following initialization 
has a 0 bit, then the message is received 
and 0 is acknowledged. 


Fol lowi ng 

DESTINATION_SEND-BIT, 

DESTINATION~SEND=BIT 
unti 1 

DESTlNATION_RECEIVE .BIT= (not BIT) ; 

-- The same acknowledgment is sent repeatedly until a packet 
— with an alternated bit is received. 
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DESTINATION.RECEIVE .BIT-BIT 
and next 

(and_next* DESTINATION J*ECEIVE«NULL) 
and next 

DESTINATION_RECEIVE .MESSAGE-MSG and DE$TINATION_RECEIVE . BIT- (not BIT) 
implies next 

DE$TINATION_OUTPUT-MSG and DESTINATION^ END- (not BIT); 

— When a change occurs in the bit of a received packet, 

— the message is supplied to the output and the new 

— bit is acknowledged. 


Fol lowing 

DE STINATION_RECE I VE .MESSAGE-MSG and DESTINATION_RECEIVE . BIT-BIT 
and next 

DESTINATION OUTPUT-MSG, 

DESTINATION J)UTPUT«NULL 
as long as 

DE$TINATION_RECEIVE .BIT/- (not BIT) ; 

— A message is supplied to the destination output only 

— when there is a bit change on the received packet. 


end; 



We have described a rigorous framework for specifying the behavior 
of concurrent systems. Among its features are: 

a Genera 1 i ty 

• Expressiveness 

• Naturalness 

The generality stems from a model of system behavior that introduces a 
minimal set of primitive concepts ~ just values and processes - and 
makes a minimal assumption - the behavior of a process is represented by 
a linear sequence of values. The express i veness reflects the approach 
adopted to specify the permitted traces of a system. Through the 
synchronic structure and logical specification, it is possible to 
express an extremely broad range of logical and timing dependencies. 

Many of these dependencies are simply not expressible with any other 
existing technique. The naturalness (or readability) results from the 
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absence of arcane notation and obscure terminology. There is very 
little new notation and the only new terminology consists of the 
connectives 'and^next 1 , 'and^next* 1 * 'or^next 1 , 'or^next* 1 , 

1 implies^next* and 'reverse*. The technical meanings of these 
connectives closely parallels their informal, i ntui tive meanings. The 
readability of a specification is enhanced when HPL is extended to 
include such higher-level constructs as "following", "until" and "as 
long as". 


8.1 Future Work 


Further development of the specification framework needs to proceed 
along several lines: 

• Improvements and Extensions 

• Verification Capabilities 

• Hierarchical Specification 

• Larger Methodologies 

The need to improve and extend the framework will inevitably arise as 
applications experience is gained. One area in need of improvement that 
has already been identified is the synchronic structure, which is 
presently limited in the sorts of synchronic relationships it can 
express . 

The desire to rigorously verify system behavior has provided much of 
the impetus for the present effort, and without a deductive capability 
the present framework remains incomplete. Such a capability has already 
been provided for a precursor to the present theory [11] [12] [ 13 ]* and 
it is possible that some of principles underlying this earlier effort 
may generalize to the present case. 

Composing (or decomposing) a specification in a hierarchical fashion 
is the most effective way of dealing with complexity. Appropriate 
mechanisms for ‘connecting 1 different levels of a hierarchical 
specification need to be developed. 

Although formal specifications of intended behavior and actual 
behavior are important elements in the design of a system, to be used 
effectively, they must be integrated with other elements in the system 
development process. The ultimate goal is a unified methodology 
encompassing: 

• Spec i f i cat i on of Mission Requirements 

• Speci f icat i on of Functional Requirements 


% 


57 




• Maintenance 
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